Visual Basic Toolbox/Visual Basic Toolbox (P.I.E.)(1996).ISO/as400/commonvb/commonvb.txt

Text File | 1995-12-24 | 38.3 KB | 821 lines

Sample VB AS/400 Client/Server Programs

  Copyright ⌐ 1995, 1996. Ron Jones.
  Genesis Software, Inc.  All Rights Reserved.

This Document

At the Chicago COMMON (IBM Midrange-Users Group) I was asked, at the last
minute, to fill in for a missing presenter and give a session addressing using VB and
the AS/400 to create client/server applications. Although I have given many
presentations on the subject in the past; I was not scheduled to do so at Chicago.
Since I had only an hour to prepare for a 2 and 1/2 hour presentation I wanted to offer
every attendee a little something extra in case my presentation did not address some
of the topics that the original session would. So I told the audience that anyone who
dropped me an e-mail on Compuserve would receive information on how to get some
of sample VB code that was reviewed at the session.

  Unfortunately I was very busy directly after the conference while I completed my
book on the same subject. Since the book was released I had some time to fulfill my
promise and have completed putting together a few sample programs and information
and have uploaded them to various forums around CompuServe.

  If you like the sample programs included, you should buy a copy of the book. The
title is "Using Visual Basic With Client Access APIs". This 650+ page guide includes
two companion diskettes that contain over 35 projects and utilities. It covers topics
such as APPC, data queues, ODBC, OLE, SQL, and many others. You can contact
Duke Press (the NEWS/400 people) at 1-800-621-1544 for more information. If your
in the UK; contact Debbie Thorton at 44 161 929 0777. If you leave "down under";
contact Melissa Hughes at 61 2891 9136. OK, enough with the sales pitch.

  If you are a COMMON member and want more of this kind of stuff (VB, Windows,
etc.) at COMMON conferences start yelling at the board and project leaders. Because
frankly I'm tired of trying to get sessions scheduled. Without exception every session
that I have ever done on the subject has been a "blow-out" and the reviews I received
later were outstanding. I'm not saying this to "bang" my own drum, but to point out
that there is a tremendous need for this stuff and you'll only have more sessions if you
scream and holler. OK, enough venting <g>.

  The remainder of this document contains information about the files that are
included in the COMMONVB.ZIP archive and other stuff. Please forgive me for any
spelling or grammar errors. I put these together at Christmas and was more
concerned about getting it out than making sure everything was just right.

  The information within this document is in no particular order and was included as an
aid to you in using the supplied sample programs and writing AS/400 CS applications
in general.

Disclaimer

Any information and/or code included within this document and/or the associated zip
archive are subject to change without notice. No warranty of any kind is made or
implied. There shall be no liability for errors contained herein or for incidental, special,
indirect, or consequential damages in connection with furnishing, performance,
content, or use of this material. Some material could contain technical inaccuracies or
typographical errors.

Required Files

The COMMONVB.ZIP does NOT contain the .VBX files (GRID, CMDIALOG) required
by a few of the programs provided. Neither does it contain the JET engine DLLs
required by the TRACKER application. If you have VB 3.0 you should already have
those files installed on your PC. Although the projects include are saved with VB 3.0;
they are completely compatible with VB 4.0.

How To Extract Files

The COMMONVB.ZIP was compressed using the 2.04 version of PKZIP and any
compatible ZIP utility should be able to unzip the file. The following steps should be
followed to replace and/or add the files to the directories.

1. Download the COMMONVB.ZIP file to your personal computer.

2. Create the directory to which you wish to install the files. The recommended name
is \GENESIS\AS400API. Using this naming convention will match the default used
with the book's companion diskettes.

2. Place COMMONVB.ZIP file in the directory created.

3. Use PKUNZIP (or some similar utility) to unzip the files as shown in the command
below:

    PKUNZIP -d COMMONVB.ZIP

      The -d optional causes the files to be restored to their original locations.

Smaller VB Font (ZZSMALL.FON)

One of the utility files provided is ZZSMALL.FON.

  If you are still using Visual Basic Version 3.0 or lower, within Windows 3.1, you have
no doubt been bothered by the font limitation in code editing windows. The
ZZSMALL.FON file lets you to overcome this limitation by providing a smaller font.

  To accomplish this change, after unzipping the COMMONVB.ZIP file, copy the
ZZSMALL.FON file found in the ..\ZZSMALL directory to your Windows system
directory (normally, C:\WINDOWS\SYSTEM). Then change the fixedfon.fon entry in
the [boot] section of your windows SYSTEM.INI file to the following value:

    fixedfon.fon=zzsmall.fon

  After saving the file and rebooting your system, both Visual Basic and the notepad
utility will use this smaller font, which will allow you to see more text within a single
screen.

  VB 4.0 provides multipoint fonts as a new feature and does away with the need to
use ZZSMALL.FON. ZZSMALL.FON does not work with Windows 95.

AS/400 Setup

The next few sections provide an overview of the steps required to create the AS/400
library and the objects in it. The library and the objects are needed to run some of the
programs provided. The books companion diskettes do all this stuff for you
automatically.

  (Note: Lines beginning with an asterisk ("*") are commands which must be executed
to properly setup the GENESIS library and other required objects.)

Creating The Library

*   CRTLIB GENESIS _
*   TEXT('Genesis Software Library')

  (Note: The underscore ("_") character indicates the continuation of the same
command on an additional line. Do not include the "_" character  when actually
entering and executing the command on the AS/400.)

  All but two of the permanent objects and source code files will need to be installed in
a single library on your AS/400. Try to use the library name GENESIS if possible. In
the examples in this document, the library name GENESIS is used. If you decide to
install to a different library, substitute the name you used were the GENESIS library is
referenced.

Creating The QGPL REXX Source File

*   CRTSRCPF FILE(QGPL/SRCREX) _
*   SIZE(*NOMAX) _
*   TEXT('Genesis REXX Source Code')

*   COPY C:\GENESIS\AS400API\SOURCE\SROBJ.REX _
*   QGPL/SRCREX(SROBJREX)

  (Note: The COPY command is not actually an AS/400 command; it indicates that
you must copy the source code referenced (in this case SROBJ.REX) from your
personal computer to the AS/400 source file indicated -- in this case
QGPL/SRCREX(SROBJREX).)

  You can use any file transfer product that supports uploading of source member
records from your personal computer to the AS/400 to copy SROBJ.REX to the
AS/400. If you do not have such a utility, you can always key the file in by hand using
SEU (ouch!).

  This REXX source code is used by the SROBJ program to restore objects from your
PC to the AS/400. Be sure that when you run SROBJ that it references the REXX
option in the library QGPL.

Restoring AS/400 Objects

You can use the SROBJ.EXE utility program provided to restore the objects required.
You can use his utility only if you have copied the REXX source code to
QGPL/SRCREX, as described above. Be sure that the SROBJ settings point to the
REXX option and the QGPL library is referenced as holding the source.

  Once you have restored SROBJRPG program (SROBJRPG.V23) you may change
SROBJ to use the RPG server option, which is much faster. For more information
about what each Save File Image (*.V23) contains, see the list below.

  SAVF Image, Description

  ECHOCBL.V23, ECHOCBL program required by ECHO
  PINGRPG.V23, PINGRPG program required by PING
  SROBJRPG.V23, SROBJRPG program required by SROBJ

  (Note: Genesis Software offers a product, Genesis Objex, which is a commercial
quality version of SROBJ. It includes many enhancements such as file compression,
drag and drop, faster processing, and no requirement for pre-existing source code or
objects on the AS/400. It uses built-in CA/400 and DDM services found on all
AS/400s.

  Genesis Objex also does not require the support of the remote command and file
transfer API interfaces. All that is required is an APPC-complaint router that supports
the EHNAPPC.DLL interface.)

  All the objects stored in the SAVF images referenced above were saved from the
GENESIS library on an AS/400 at V2R3M2. When saved, the objects were assigned
*ALL *PUBLIC authority and the owner was QUSER. After they are restored to your
system you can change the security options as your installation needs warrant.

Creating Programs

If you are unable to restore the SAVF images to the GENESIS library with the SROBJ
utility, you can create the required server programs required by using the standard
AS/400 utilities. Of course, you must upload the source members beforehand or
entered them in using SEU (ouch, again!). All the programs are listed below, along
with the corresponding PC file (found in the ..\SOURCE directory) that contains the
source code, and a description of the program.

  Program, Source Code, Description

  ECHOCBL,  ECHO.CBL,  Echo COBOL Program
  PINGRPG,  PING.RPG,  Ping RPG Program
  SROBJRPG,  SROBJ.RPG,  Save/Restore Server RPG Program

Creating The GENESIS Output Queue

*   CRTOUTQ OUTQ(GENESIS/GENESIS) _
*   TEXT('Genesis Output Queue')

  You can create the GENESIS output queue in the GENESIS library. This output
queue is not required for any program to work, but is handy if you want to set up a
user profile that references output queue. You might use this output queue to make it
easier to locate spooled output that is generated while you are testing the programs
provided.

Creating ICF Files AND Device Entries

*   CRTICFF FILE(GENESIS/ECHOICF) _
*   SRCFILE(GENESIS/SRCICF)

*   ADDICFDEVE FILE(GENESIS/ECHOICF) _
*   PGMDEV(ECHOICF) _
*   RMTLOCNAME(*REQUESTER) _
*   CNVTYPE(*USER)

*   CRTICFF FILE(GENESIS/PINGICF) _
*   SRCFILE(GENESIS/SRCICF)

*   ADDICFDEVE FILE(GENESIS/PINGICF) _
*   PGMDEV(PINGICF) _
*   RMTLOCNAME(*REQUESTER) _
*   CMNTYPE(*APPC)

  The APPC Basic Conversion Demonstration Program (ECHO) and the APPC
Mapped Conversation Demonstration program (PING) require the existence of the
ICF files and device entries shown above. To create these ICF files and device
entries, enter the commands show above.

The GENESIS Library

  After you complete the setup process or the manual steps to create and set up the
GENESIS library, you should find the following objects in GENESIS.

    Object, Type, Description

    ECHOCBL,  *PGM (CBL),  Echo Cobol Program
    PINGRPG,  *PGM (RPG),  Ping RPG Program
    SROBJRPG,  *PGM (RPG),  Save/Restore Server RPG Program
    GENESIS,  *OUTQ,  Genesis Output Queue
    ECHOICF,  *FILE (ICFF),  Echo ICF File
    PINGICF,  *FILE (ICFF),  Ping ICF File

Omitting The AS/400 Setup

Since you are manually setting up the client/server configuration, something that
happens automatically if you purchase the book and it's companion diskettes, several
INI files will not be properly built. These INI files need references to the AS/400 library
and programs, which must be installed for them to execute properly.

  If you attempt to run a program and a message tells you that a certain INI file has
not been set up, you need to manually place the proper entries into the INI file after
you have installed the Server components on your AS/400. You must remember that
many of the programs install on your PC rely on AS/400 counterparts to do their work;
if they have not been installed, the programs cannot function!

  For example, the PING and ECHO programs found in the ..\APPC directory both use
the APPC.INI file. Each section within the INI file has a System= and Library= entry. If
you install the AS/400 objects during the setup process to an AS/400 named
BIGBLUE in library GENESIS2, the following entries, along with others, would be
found:

    [ECHO]
    System=BIGBLUE
    Library=GENESIS2

    [PING]
    System=BIGBLUE
    Library=GENESIS2

V3R1 Changes To Shared Folders

Beginning with V3R1, IBM has introduced a new file system known as the Integrated
File System (IFS). This change has a direct effect on shared folder functionality.
Before V3R1, all objects, including shared folders, originated from the QSYS OS/400
library.

  The IFS introduces a layer on top of QSYS, making it just another entry in the "root".
The propose of the IFS is too allow the AS/400 to service various file systems and
prepare it for the future as IBM's "Server Of Choice". Hey, I'm excited! The IFS
enables IBM to add new hardware and software, such as the FSIOP and UNIX
compliant file systems. The IFS is intended to provide a common interface to all the
objects on the AS/400.

  In many cases, if you are not aware of the IFS, you'd never miss it. In fact, if you
have a CA/400 client that is running pre-V3R1 code, you will not be able to access
any of the new V3R1 code and files that reside in the new IFS layer below QSYS.
That is why IBM provided a migration aid that allows your pre-V3R1 client to access
the required files and data found within the IFS by coping them to shared folders.

  With V3R1, the "root" shared folder is now designated as part of the QDLS
(document and library services) file system (more on that in a minute); so the shared
folder mappings shown below are equivalent.

  F: \\BIGBLUE\QIWSTOOL (Pre-V3R1)
  F: \\BIGBLUE\QDLS\QIWSTOOL (V3R1)

  Be aware that with V3R1, when IBM refers to a directory such as QPWXCWN (new
CA/400 code), it is referencing the \QPWXCWN folder and not the
\QDLS\QPWXCWM folder (used for PTFs and temporary code).

  IBM has provided new commands that allow you to work with the IFS from the
AS/400 command line. These include the CPY command, which functions like the
PC's COPY or XCOPY command; and the MD command, which -- like its PC
counterpart -- creates subdirectories.

  The commands shown below demonstrate the copying of Windows client files to
shared folders which would be accessible by pre-V3R1 clients.

  MD DIR('/QDLS/CAMIGRAT')
  MD DIR('/QDLS/CAMIGRAT/MRI2924')
  CPY OBJ('/QPWXCWN/*') TODIR('/QDLS/CAMIGRAT')
  CPY OBJ('/QPWXCWN/MRI2924/*') TODIR('/QDLS/CAMIGRAT/MRI2924')

  With V3R1, the familar AS/400 library is just another entry in the IFS and you always
have a current location (library) within the IFS structure. Your AS/400 user profile
determines your default home location which will be your current library when you first
signon.

  The IFS will eventually offer seven unique file systems; including the "root" system,
the QLANSrv system, the QOpenSys system, the QSYS.LIB system, and the QDLS
system. The QFileSvr.400 and QOPT (optical disk) file systems will not be available
until V3R6. The "root" system supports directory and file names up to 256 characters
in length and names are not case sensitive. The QOpenSys supports the same file
name length as "root", but names are case sensitive. QSYS.LIB contains all the
familiar OS/400 objects. Each library appears as a subdirectory under the QSYS.LIB
object. QSYS.LIB supports a 10.6 naming convention. The QDLS file system
supports DLO (document library objects) and shared folders. It supports a 8.3 naming
convention. The QLANSrv system provides support for the new FSIOP offerings.

  New IFS APIs are available for working with the various file systems referenced
above. "Using VB With CA/400 APIs" only deals with shared folders support (QDLS).
Hey, I had to leave something for volume 2! Anyway, I was given a 700 page limit!

Confirm After Allocate Required

In some cases, it may be necessary to issue a call to the EHNAPPC_Confirm API
directly after an allocation to insure that the APPC conversation is in "synch". Using
the API addresses a problem you might encounter. After you allocated a conversation
and attempt to send data to the AS/400 program, everything may appear to be OK but
no data is received by the AS/400 program. If you run across this problem, calling the
EHNAPPC_Confirm API, before sending the data, might help clear it up. See the
zzCAConfirm wrapper in ZZPAPW2.BAS for an example of using
EHNAPPC_Confirm.

ICF Entries For Basic And Mapped Conversations

One common error that people make when they are setting up the ICF device entry
required to execute APPC conversation if the incorrect entry of parameters for the
ADDICFDEVE command. Dependent on whether you are setting up support for a
basic or mapped conversation the value will be different. Consider the examples
below.

    ADDICFDEVE FILE(GENESIS/ECHOICF) PGMDEV(ECHOICF) _
    RMTLOCNAME(*REQUESTER) CNVTYPE(*USER)

    ADDICFDEVE FILE(GENESIS/PINGICF) PGMDEV(PINGICF) _
    RMTLOCNAME(*REQUESTER) CMNTYPE(*APPC)

  The first entry is for a basic conversion because the conversation type (CNVTYPE)
parameter has been set to *USER. This means that the user-written program will
have handle the header/error information. The second example shows the correct
entry for an APPC conversation. Note that the CNVTYPE parameter is omitted and
the communications type (CMNTYPE) parameter is specified as *APPC. This
indicates that the "mapping" of the header/error information will be handled
automatically by APPC support.

Close Before Ending Transfer Request

Although the IBM documentation would suggest that after you perform a transfer
request you can end the conversation and any open files will be closed, I have found
that this sometimes leads to errors. This is especially true when doing uploads. I
recommend that after you complete a file transfer, you always close the file by calling
the zzTFClose wrapper before calling the zzTFEndConversation wrapper.

Notes About Version Checking And Stamping

The ODVERCHK program allows you to address problems that can  occur when
version stamping is not done properly and how it can make your life difficult. This
section presents examples of some of the problems that might occur. This section will
definitely put the "fear of software" into your heart.

  Suppose vendor A and B use a common DLL named COMMON.DLL in their
products. Maybe its a DLL that contains great sort routines. Vendor A has been
working on its product for three years (must be an IBM spin-off company) and is
stilling using version 1.0 of COMMON.DLL.

  Vendor B has produced a product which also uses COMMON.DLL, but has kept up
to date by developed their product using version 2.0 (the latest version). When you
buy vendor B's product and when you run their setup/installation, COMMON.DLL
(version 2.0) is installed in your Windows system (e.g., C:\WINDOWS\SYSTEM)
directory. So far, everything is cool!

  Now you buy Vendor A's product and run the setup/installation for it. Some time
during the setup/installation process, COMMON.DLL must be installed. Several
scenarios are possible at this point -- most of them are bad!

  If Vendor A is a "responsible" vendor, its setup/installation program will be smart
enough to recognize that a more recent version of COMMON.DLL is already installed
in C:\WINDOWS, and it will do nothing. No problem here, maybe (see below). But the
setup might be "stupid" and copy the older version of COMMON.DLL over the top of
version 2. This causes no problems for Vendor A's product, it was designed to work
with version 1.0. So Vendor A has nothing to worry about. But what happens when
you try to run Vendor B's program? If your lucky, its program will also work with
version 1.0. But if Vendor B's product requires an API or function that was introduced
with version 2.0 of COMMON.DLL -- you guessed it -- Vendor B's product is dead in
the water!

  Another possible scenario is that Vendor A's setup program installs version 1.0 of
COMMON.DLL into another directory (e.g., C:\WINDOWS), or in the directory where
the program is installed. Now you have two versions of the same DLL on your system
and depending on how you have your PATH set up; the programs from vendor A and
B may or may not work.

  Vendor A's setup program may be smart enough not to install version 1.0 of
COMMON.DLL, because it sees a more recent version 2.0 of COMMON.DLL is
already installed. Vendor A's setup program is saying "OK, I see a newer version
(2.0) of COMMON.DLL, so I'll use it instead of my older 1.0 version". This is great if
the developer of COMMON.DLL has not introduced any incompatibilities between
version 1.0 and 2.0. Version 1.0 will be left on Vendor A's setup disk and only version
2.0 will be on your hard drive. But what if COMMON.DLL version 2.0 does not support
programs written to use COMMON.DLL version 1.0. Now we have real problems!
Vendor B's program still works fine. Remember it was developed to use version 2.0 of
COMMON.DLL, which was installed when you installed Vendor B's product. But
Vendor A's program, that you just installed, won't work because it was designed to
use version 1.0 of COMMON.DLL. Vendor A has followed all the rules (other than not
keeping up with changing versions of COMMON.DLL) but now their program won't
run. This scenario is rare, but not unknown. Have you had problems with
THREED.VBX or GRID.VBX? Now you understand why developers are so concerned
with maintaining backward compatibility of files such as our example COMMON.DLL.

  Another problem might occur if the different versions of COMMON.DLL have no
version information. How do you know know version is which? You can't always go by
the dates of files, because these can be easily changed. Basically, you're out of luck
in this situation. Unfortunately, this situation happens much to often. For example,
IBM doesn't even version stamp its CA/400 DLLs! Write your congress person now!
Being able to keep files straight when they have no version information is a hit-or-
miss proposition.

  To add more fuel to the fire, what happens if another component provider decides to
provide a great new DLL that does all kinds of neat things, and they decide to name
their new component -- you guessed it -- COMMON.DLL! Then Vendor C develops a
new product using this other COMMON.DLL component. The fun really begins when
you install Vendor C's product!

  I warned you before you started reading this section! Don't worry, I'm sure your files
are all correct, and your using the most up to date available!

Using the WPS.EXE Utility

In addition to the ODCHKVER.EXE, supplied with the companion diskettes, a VB
utility that you might find very helpful is WPS.EXE. This program, installed with VB,
can be found in the \VB\CDK directory. It displays a map of all programs and DLLs
loaded into your PC's memory. This information is very useful in determining which
DLLs are actually being used by Windows, and your programs.

Using Basic DOS Support With Windows 95

It is possible to use the basic (not extended) version of PCS/400 with Windows 95.
Remember that you will be unable to use any of the APIs because they all require that
the extended DOS router be running. If you have upgraded to V3R1M1, see "Using
CA/400 With Windows 95" below.

  Here are the steps required to setup configuration diskettes that let you install DOS
basic support on a Windows 95 PC. To perform the tasks outline, you must have a
PC that is using PCS/400.

    Use the PC Support Administration Program (PCSWADM.EXE) to create a
configuration using the basic DOS option. You will need 4 or 5 formatted diskettes
(HD) to create a complete install set. Follow the instructions provided by
PCSWADM.EXE.

    On the Windows 95 PC, access the Control Panel (available through the Start
menu) and select the Network icon. Click the Add button under configuration. Choose
protocol and once again click the Add button. Choose Microsoft and MSDLC. The
MSDLC protocol will be loaded into Windows 95, but we still need to make changes to
the AUTOEXEC.BAT file for basic DOS services.

    Open a DOS window and make a backup copy of AUTOEXEC.BAT, CONFIG.SYS,
STARTPCS.BAT. Then run the CA/400 install from the diskettes that you created
earlier. Normally, the install would go to the C:\PCS directory. Remove all changes
made by the install (copy the backup versions of the files to the changed originals).
You will need to make the changes shown below.

      Be sure that your CONFIG.SYS has, at a minimum, the following entries:

        DOS=HIGH
        DOS=UMB
        FILES=99
        DEVICE=C:\PCS\EIMPCS.SYS

      Be sure that your AUTOEXEC.BAT has, at a minimum, the following entries:

        PATH=...C:\PCS;
        C:\WINDOWS\MSDLC.EXE
        C:\PCS\STARTPCS

    C:\PCS must be somewhere within your path statement. MSDLC must be run after
you have initialized your network connection but before you log on. Dependent on
your network, you may need to play with this one to get it right.

    Be sure that your STARTPCS.BAT file has no reference to shared folders, the
update function, virtual printing, or data queues. Sorry, they don't work. Basically, all
you need is the STARTRTR command (which you may just move to the
AUTOEXEC.BAT file if you wish).

  After restarting your computer the following functions should (notice I said should!)
work:

    PC Support Administration (PCSWADM)
    PC Support Menu (PCSMENU)
    File Transfer (both ways)
    PC to AS/400 file transfer
    The workstation function
    Rumba terminal emulation
    Rumba printing.

    The workstation function (WSF.EXE) works, but if you end it and try to execute it
again it will fail. Although Rumba will work, the fast path, auto connect, and session
configuration options will not function.

    You'll need to install, set the connection type to "PC Support", and save the
configuration. Use the saved configuration as a shortcut on the Windows 95 task bar.
You'll have to click Session/Connect each time you start Rumba.

  Remember that IBM does not support this kludgy configuration, so don't expect any
help from BIG BLUE. Whoops, I forgot; they can't use the BIG BLUE reference
anymore<G>!

  Good luck and may the force be with you! Hey get to V3R1M1 as soon as possible!

Using CA/400 With Windows 95

As this book was being prepared for publication, I was attempting to get the CA/400
V3R1M1 client code to work within the Windows 95 environment. Although my
success has been mixed up, I thought I'd shared with you information provided to me
by IBM. This information mighthelp you to use the CA/400 For Windows 3.1 client in
Windows 95 successfully.

  Remember that IBM does not support the use of its clients in the Windows 95
environment. All the information below is strictly beta work. To have any hope of
success, you must use the V3R1M1 CA/400 For Windows 3.1 client. DO NOT try this
configuration within a production environment unless you are looking for a career
change!

  The following PTFs need to be applied to your V3R1 system:

    APAR, PTF, File

    SA46324, SF25773, VREFLECT.386
    SA46342, SF25785, EHNSFW.DLL
    SA46100, SF25550, VNCD.386
    3600058, SF25251, NOFNSD.DLL
    3992942, SF25788, EHNEC.DLL
    GUI/400, SF26463

  After applying the PTFs, you need to copy the files listed above to your CA/400
directory on your personal computer. If you are doing a new install of CA/400 For
Windows 3.1 on your Windows 95 PC, you must first apply the PTFs to your AS/400
and build a new set of install diskettes from the AS/400 that will automatically include
the fixes. This can be done by running the CA/400 administration program on any
currently functioning CA/400 For Windows 3.1 client PC.

  Another possibility is that you have already installed Windows 95 onto a PC that has
CA/400 for Windows 3.1 installed on it, and the PC currently does not work. If this is
the case, you can copy the fix files from the AS/400 using shared folders on a
different PC where Windows 3.1 is installed, and then manually copy the files to the
Windows 95 PC into the CA/400 directory (normally C:\CAWIN).

  For the LAN based router, you can use either the IBM LAN Support Program or the
Microsoft DLC (MSDLC is available on the NEWS/400 CompuServe Forum) and the
following steps must be taken:

    Using the IBM LAN Support Program (not recommended)

      Disable all networking functions in Windows 95 by

        1. Select Start
        2. Select Settings
        3. Select Control Panel
        4. Select Network
        5. For all installed components select the component
            and select the REMOVE button.

    OR

    Using the Microsoft DLC driver (recommended)

      1. Select Start
      2. Select Settings
      3. Select Control Panel
      4. Select Network
      5. Select Protocol
      6. Select ADD Button
      7. Select Microsoft
      8. Select Microsoft DLC and press OK
      9. On the main network control panel
          dialog select Microsoft DLC

         With in Advanced tab window, select properties, and
         set the following parameters:

           SAPS=8
           STATIONS=20
           xsaps0=5
           xstations0=5

    If you are using the IBM Token-ring Adapter you must modify the default transmit
buffer size as follows:

      1. Select Control Panel
      2. Select Network
      3. Select IBM Token-ring card Properties
      4. Select the advanced TAB
      5. Change the Transmit Buffer Size from 1024 to 2040

  A manual entry in your Windows WIN.INI configuration file is required. Open the file
using any text editing utility, such as NOTEPAD, and add the following entry into the
existing [ModuleCompatibility] section:

    LANNSD=0x0001

  With this configuration, certain restrictions do apply, including:

    1. The Graphical Access/400 function of Client Access/400 does not currently
        work. A PTF will be forth coming to correct this.

    2. If you Install Client Access/400 for Windows 3.1 to a new Windows 95 PC
        without the fixes on the install diskettes, the install will fail.

    3. When installing the Rumba/400 function from the Setup program, no icons will
        be created. This can be corrected by the following steps.

      a. Select Start/Settings/Taskbar
      b. Select Start Menu Programs / Advanced
      c. Select Programs
      d. Select menu item File/New/Folder
      e. Type "Client Access 400 Rumba" as the folder name
      f. Double click on "Client Access 400 Rumba"
      g. In the empty contents section click your right mouse button
      f. Select New/Shortcut from the menu bar
      h. Select Browse RUMBACAW
      i. Select RUMBAWSF.EXE for "Rumba - Terminal"
      g. Push the Next button
      h. Name the Icon "Rumba - Terminal" and push the finish button

      Repeat steps g-h for the following applications:
        RUMBAPRN.EXE for "Rumba - Print"
        RUMBA.EXE for "Rumba - Main"

      i. Select main menu option File/Close
      j. Push the OK button on the taskbar properties

    To run Rumba function from the main Start menu select the "Client Access 400
    Rumba" menu, and your desired icon.

    4. Microsoft's DLC does not function properly with certain Pentium machines. Do
        not assume that MSDLC is not the cause of any problem you might experience.

  (Note: I've had reports that Microsoft support is telling people all they need to run
CA/400 within Windows 95 is an updated version of a file named NOFNSD.DLL.
According to IBM this is not true and they are telling the truth. Microsoft is also
claiming that Basic DOS PC Support will work under Windows 95. While this is true,
IBM says they will not support it and that only the updated Windows V3R1M1 client
(available 1996) will be officially supported.)

  (Note: One problem that you may encounter with Windows 95, if you are using
Novell SAA, is a message that the IPX/SPX support is not started. If you are using the
32-bit Novell client this is possible since it is loaded as a virtual device driver (VxD)
after AUTOEXEC.BAT has been run. You can overcome this limitation by moving the
AUTOEXEC.BAT code, related to start the router, to WINSTART.BAT in the
WINDOWS directory. The commands in this file are executed after the VxDs are
loaded; so IPX/SPX support will be "seen" by the STRNRTR.EXE and PCSWIN.)

  Good luck!

WWW Sites

The following list includes additional WWW sites that might be of interest to AS/400
developers and users.

Duke Communications International
http://www.duke.com/

IBM AS/400 Home Page
http://as400.rochester.ibm.com/

IBM AS/400 Services
http://as400.rochester.ibm.com/QDLS/400home/service/serv_m.htm/

IBM Book Ordering
http://booksrv2.raleigh.ibm.com/

IBM Personal Software Services
http://ps.software.ibm.com/

IBM Global Network
http://www.ibm.net/

IBM Home Page
http://www.ibm.com/

IBM Networking Home Page
http://www.raleigh.ibm.com/

IBM Red Books
http://www-i.almaden.ibm.com/redbooks/

Netsoft
http://www.netsoft.com/

ShowCase
http://www.bismark.com/showcase/

Some Thoughts

First of all, if you've been waiting for this file since the Chicago COMMON -- my
apologies. I have included a few personal thoughts about AS/400 client/server
application development.

  In the world of AS/400 client/server computing there are many ways to "skin a cat".
People are always asking me what the best solution is; or what is the best way to
design an application. I tell them there are a number of ways most applications can be
done -- this is always true. I have found; however, that the most robust, reliable
applications that I have developed rely on APPC itself.

   The scenario of a developer written client program (that for me is almost always VB
with a pinch of Visual C++ and Delphi) and a developer written server program (that
for me is almost always RPG) communicating through APPC APIs can't be beat for
performance and reliability. True, these solutions are generally more complicated to
code and implement; but once you've got them working, they are very solid.

  Remember that almost all the other APIs use APPC to communicate and they rely
on IBM provided utilities and servers to "ride the APPC wave". That convenience
comes at a price -- less performance and lack of control over specific features of your
application.

  ODBC is promising and you can do some great stuff with it. But the QSYS file
system, at this point, just does not always match up well ODBC. With V3R1, IBM has
done a lot to change that. But why do you think IBM is introducing all these new file
systems into the AS/400? Think about it!

  Over the next year, I see myself continuing to write both the client and server
components for new applications. I'll probably move toward CPI-C since it provides a
slightly cleaner interface than APPC. TCP/IP will also be playing a greater role in what
I do. The new object management APIs are neat and I've played with them some. But
they really don't do much for normal applications that don't do much generic stuff with
AS/400 objects but almost always deal with manipulating data. I'm doing more work
with the built-in support provided by IBM's DDM servers and have managed to do
some exciting stuff. A lot of the functionality of Genesis Objex relies on the
capabilities within DDM.

  I'm anxious to look at the new 32-bit support IBM, and others, will provide for
Windows. That's were the cooperate world will be heading -- none to slowly. I'm a big
believer in Windows NT and IBM has got to get on the bandwagon with it. I've already
seen some movement by IBM in that direction. 32 bit development is were it's at now,
or will be very shortly. I'll be learning more about VB 4.0 over the next year. Borland
will shortly be coming out with their 32-bit Delphi product. I plan to use Delphi more
over the next year. Mainly in applications were I don't want the overhead of the OLE
baggage that VB 4.0 carries.

  The AS/400 is a marvelous machine; rock solid. If the shops I do work for had
AS/400s that were as unreliable as the LANs and WANs that surround them, then
many an AS/400 professional would be "sleeping with the fishes" today. You can
bellow all you want about this fact, say forget those PC toys, but the big picture is that
LANs, WANs, and PCs are here to stay. Don't doubt that for a second. They will be
the players; and if IBM can have the AS/400 become a valuable, stable, resource-
filled component in that world then they've got something.

  Today, I believe the future of the AS/400 in a client/server world is getting brighter.
Anyone who knows me will tell you I didn't feel that way not to long ago. Good luck in
your endeavors trying to make the AS/400 work for your client/server applications!

  I hope the sample programs provided you with some good basic (no pun intended)
examples of AS/400 client/server programs.

Ron Jones, CCP
Genesis Software

Genesis Software

  Feel free to distribute the COMMONVB.ZIP file to whomever. It's free for the using.
Just remember that all the code comes with no guarantees; so check out your
programs that use the code very carefully. By the way, we do sell code and programs
that we guarantee will work. For more information about Genesis Software and the
products and services we provide contact:

  Genesis Software, Inc.
  2709 Penny Lane
  McKinney, Texas 75070
  CompuServe: 75070,2615

..Ron Jones

Description For Forum Upload of COMMONVB.TXT

12/24/95 update to text file describing the purpose and contents of the
COMMONVB.ZIP file. This file also contains information about the downloading and
installation of the COMMONVB.ZIP file. Ron Jones.

VB CA400 APIS API AS400 CLIENT ACCESS GUI

Description For Forum Upload of COMMONVB.ZIP

12/24/95 update for zipped file containing sample programs and information about
using VB to develop AS400 client/server applications. Enjoy! Ron Jones.

VB CA400 APIS API AS400 CLIENT ACCESS GUI